Information Technology (IT) management has become an increasingly complex task for a large organization. There may be thousands of users (e.g. employees) carrying their own individual endpoint devices (e.g. laptops, workstations, smart phones, tablet computers, etc.) and each device may have an abundance of software and applications that are operating on the device. Some of these applications are unique to each individual user, while others are identical across several devices or at least share some of the same components (e.g. files, registry entries, data). Users generally want the freedom to install whatever software and applications they choose while IT departments are faced with the need to maintain compliance and data protection across this complex ecosystem. For example, a typical IT department today needs to be able to manage, secure and deliver applications to users, distribute software updates, as well as be able to back up and restore any user's data and settings on demand.
One requirement for managing applications on such a large scale is being able to produce an application package that can be distributed from a central location to a large number of endpoint devices, where the package can be deployed and executed. There exist a number of software solutions, sometimes referred to as “application capture” systems that attempt to aid organizations in creating such packages. For example, the System Center Configuration Manager (SCCM) available from Microsoft Corporation; the LANDESK Management Suite (LDMS) available from LANDESK Software; and the Client Management Suite (CMS) available from Symantec Corporation; all take different approaches in assisting an IT administrator in application management, including in some cases capturing an application package that could be delivered to end user devices.
Conventional solutions for the capture, delivery and management of applications often leverage recording technologies during the application installation. This generally means that each application must first be installed separately on a dedicated clean staging machine, which could be a virtual machine or a physical computer. For example, one type of process for capturing an application first records the state of the system on the staging machine prior to installing an application (i.e. captures a pre-installation snapshot) and then records the state of the system again after the application has been installed (i.e. captures a post-installation snapshot). Based on a comparison of the pre-installation snapshot and post-installation snapshot, the system is able to compute a delta that indicates which files and registry entries were added, removed, and modified during the installation process. This delta can presumably then be used to determine which components (files, registry entries, etc.) actually comprise the application so that a package containing those components can be created and delivered to multiple endpoint devices.
However, the type of process mentioned above suffers from a number of shortcomings, including the possibility of missing some necessary components of an application. In some situations, the application installation process may require certain files which were already present on the device before the installation and, as such, the installation process might not actually affect those files. In such cases, the pre-installation/post-installation comparison would not indicate that these files were modified by the installation process and, consequently, those files would not be included in the application package. One simple example of such a situation occurs when the capture process attempts to install Microsoft Visio application on a staging machine that already has Microsoft Office preinstalled thereon. Since Microsoft Office contains many of the files that are necessary for Visio, merely looking at the post-installation changes on that machine would not yield all of the required components of Visio. Therefore, when such a package is delivered to another machine (which does not have Microsoft Office preinstalled thereon) the application would not function properly. Additionally, conventional application captures may also be vulnerable to capturing “noise” along with the target files. For example, between the time of pre-installation snapshot and post-installation snapshot, another application may have updated itself, an operating system update may have applied, or another change taken place. The change may have added or modified certain files which are actually unrelated to the application installation, but these changes would be included in the captured package. Including such noise in the application package may cause problems when delivering the package to other machines. Yet another limitation of conventional application capture process described above is that it requires a recording of the pre-installation state, which is not always available in the first place; for example, in the case of legacy applications.
It should be noted that the process described above is just one example of an application capture and not all of its shortcomings may be applicable to all such systems. However, most conventional application capture systems still suffer from at least one form of inefficiency or another. Generally speaking, the inherent difficulty in trying to create an application package using conventional capture systems stems from the large numbers of users, devices and types of software that are involved. Organizations may reach inventories with thousands or even tens of thousands of applications, each of which requires a significant investment in time and resources to capture. Many organizations are intimidated by the amount of work and resources they will need to invest in order to start managing the applications. At the same time, those that are willing to perform all the required manual work to capture applications soon find out that this is an on-going, never-ending process, since for every new version of an application the administrator needs to re-capture the application and repeat the process. Additionally, many conventional application capture systems suffer from incomplete captures and noise during the capture process mentioned above. All of these vulnerabilities cause malfunctions as well as incorrect and unexpected behavior when trying to use the captured application on the endpoint devices. This represents an additional pain point for the organization—testing that the application capture was indeed successful and will work as expected on the end user's actual environment. In light of all of these shortcomings, a more efficient system for capturing and managing applications is needed.